home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000176_owner-urn-ietf _Fri Nov 15 14:03:06 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA16096 for urn-ietf-out; Fri, 15 Nov 1996 14:03:06 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA16088 for <urn-ietf@services.bunyip.com>; Fri, 15 Nov 1996 14:02:55 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA29813  (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 14:02:09 -0500
  5. Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
  6.           id <00965-0@josef.ifi.unizh.ch>; Fri, 15 Nov 1996 20:01:44 +0100
  7. Subject: Re: [URN] URI internationalization
  8. To: rdaniel@acl.lanl.gov (Ron Daniel)
  9. Date: Fri, 15 Nov 1996 20:01:43 +0100 (MET)
  10. Cc: urn-ietf@bunyip.com
  11. In-Reply-To: <2.2.32.19961115160551.006f3f5c@acl.lanl.gov> from "Ron Daniel" at Nov 15, 96 09:05:51 am
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=US-ASCII
  14. Content-Transfer-Encoding: 7bit
  15. Content-Length: 3556
  16. From: Martin J Duerst <mduerst@ifi.unizh.ch>
  17. Message-Id: <"josef.ifi..656:15.10.96.19.01.46"@ifi.unizh.ch>
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Martin J Duerst <mduerst@ifi.unizh.ch>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. Hello Ron - Many thanks for your comments. Hope to get more
  24. of these from others in this group.
  25.  
  26. >Thus spoke Martin J Duerst (at least at 03:57 PM 11/15/96 +0100)
  27. >
  28. >>The internationalization of URNs, URLs, and URIs in general has been
  29. >>raised as a problem or topic in many different places. Given the
  30. >>various recent discussions and the progress made in particular in
  31. >>this group, I think that time has come to address this issue in a
  32. >>more formal way, inside an existing ietf working group or by creating
  33. >>a specific working group for it.
  34. >
  35. >I think I18N for URLs is a more difficult problem than it has been for
  36. >URNs. We have a large number of existing URLs in a variety of character
  37. >sets. Saying "thou shalt use 10646" will meet more resistance than it
  38. >has in this WG, due to backward compatability considerations.
  39.  
  40. I am very aware of this problem. A lot of it has been discussed e.g.
  41. in the ftp-wg. The basic idea is to have each protocol (and within
  42. that each server) stay with what they have used, but to convert
  43. to using e.g. UTF-8 if and when identification of characters (as
  44. opposed to raw octets) is desired.
  45. Awareness of this fact is why I was repeatedly adressing the question
  46. of what happens with URNs if they don't form correct UTF-8 sequences.
  47.  
  48. >The first
  49. >question that has to be answered is "Is an I18N scheme for URLs that
  50. >breaks existing URLs acceptable or unacceptable?". If the answer is
  51. >"unacceptable" you have a tremendous technical problem. If the answer
  52. >is "acceptable" you have a MUCH bigger social problem.  Call me a
  53. >coward, but I want no part of the second battle. I want to get on to
  54. >URCs before *all* my hair turns grey.
  55.  
  56. By getting aware of the fact that correct UTF-8 sequences are really
  57. rare in current URLs, you get more than you would expect.
  58.  
  59. >While I18N for URLs is a legitimate issue, it is not an issue for the
  60. >URN-WG (IMHO). The URI list is still alive, that might be the proper
  61. >place to begin discussions. I suggest that you wait until the recent
  62. >agreements on UTF-8, %HH, ... for URNs have been codified in the
  63. >Syntax draft, but that is only a suggestion.
  64.  
  65. Many thanks for these suggestions. One reason of why I wanted to
  66. initiate some discussion now is because next week, there will be
  67. a meeting on WWW i18n in Sevilla, and URI i18n will be one important
  68. topic.
  69.  
  70.  
  71. >>The aim would be to produce a document that would include:
  72. >[specific points deleted for brevity]
  73. >
  74. >What you have outlined appears reasonable, but may be best
  75. >handled as a series of documents. As you have outlined it,
  76. >I think you are talking about a 100 page informational RFC.
  77.  
  78. I guess it will be smaller. I guess we might start with
  79. one document, and split when it gets too large.
  80.  
  81. >>- What is the best framework/place/list to host this activity.
  82. >
  83. >Your friendly area directors can advise you on this. I suggest
  84. >you come up with an outline of your solution and then ask them if
  85. >it needs a WG or if they want to do a special "last-call" to the
  86. >URI list and some selected experts.
  87.  
  88. At present, it looks to me like the solution is more or less
  89. defined. Writing the document(s) of course will take some more
  90. time.
  91.  
  92. >Peer-review of a concrete
  93. >proposal seems to work much better than design by committee.
  94.  
  95. The reason why I would like to have a WG, or do the work in
  96. the context of a WG, is that I don't want to submit drafts
  97. and RFC in person. Discussions always bring up points that
  98. would have been forgotten, and the work of a WG has (hopefully)
  99. more influence that the work of one or two individuals.
  100.  
  101.  
  102. Regards,    Martin.